home *** CD-ROM | disk | FTP | other *** search
- ****************************************************************
- * Version 2.2 *
- * The TSR package includes programs useful in managing *
- * DOS memory, and in particular managing memory-resident *
- * utilities. TSR stands for "Terminate and Stay Resident". *
- * *
- ****************************************************************
-
- A. MARK, FMARK and RELEASE
- ================================================================
-
- MARK.COM and RELEASE.COM are used to remove memory-resident
- programs from memory, without requiring a system reboot, and
- without the usual problems of creating holes or leaving
- interrupts dangling. The two programs are used simply as follows:
-
- 1) Run the program MARK.COM before installing any memory-
- resident program that you may wish to deinstall later.
- This marks the current position in memory and stores the
- DOS interrupt vector table (all interrupts from 0 to FFH).
-
- 2) Install whatever TSRs that you want to use, in the normal
- way that you install them.
-
- 3) When you want to deinstall all TSRs above the last MARK,
- run the program RELEASE.COM. This will release all of the
- memory above (and including) the last MARK, and restore
- all interrupt vectors taken over by the memory resident
- programs.
-
- MARK and RELEASE can be "stacked" as many times as desired.
- RELEASE releases the memory above the last MARK call. MARK uses
- about 1600 bytes of memory each time it is called. This 1600
- byte region is also released when a RELEASE is done. MARK memory
- usage is dominated by the copies of the DOS interrupt vector
- table (interrupts 0..FFh) and the copy of the EMS page map
- (blocks 0..31 only) which MARK keeps when it goes resident.
-
- ================================================================
-
- MARK and RELEASE can optionally be called with a single command
- line parameter:
-
- MARK MarkName
- RELEASE MarkName
-
- In this way a particular mark is given a name. Calling RELEASE
- with the same name will release all memory above and including
- the mark of that name, also releasing any intermediate marks in
- the process. If no mark of the proper name is found, RELEASE
- will halt with a warning. A RELEASE call with no MarkName
- specified will release the last MARK, whether or not that MARK
- was named.
-
- The MarkName can be any text string up to 126 characters in
- length. It may not contain embedded blanks or tabs. Case (upper
- or lower) is not important when matching MarkNames.
-
- MarkName supports an additional feature. If the MarkName begins
- with ! (exclamation point), then the mark is called a "protected
- mark". That mark can be released *only* by an exact match to its
- name (including the exclamation point). A protected mark will
- NOT be released with an "unnamed" RELEASE. Any named or unnamed
- RELEASE will stop without releasing any memory if it encounters
- a protected mark that it does not match exactly.
-
- ================================================================
-
- As of version 1.4, MARK and RELEASE also control Expanded memory
- (Lotus/Intel/Microsoft EMS). They have been tested with READY!
- and with the TurboPower Software expanded memory disk cache, as
- well as with the device drivers used by the STB Expanded Memory
- Card.
-
- WARNING: if a resident application allocates expanded memory at
- some time *after* going resident and after the last MARK made,
- that expanded memory will be released by a call to RELEASE. The
- current expanded memory manager (EMM) does not give us enough
- information to avoid this possibility. Fortunately, there are no
- known memory resident programs which perform this dynamic
- allocation of expanded memory. We hope that the EMM will be
- upgraded before such applications are designed.
-
- ================================================================
-
- As of version 1.6, RELEASE takes special precautions to allow it
- to release extra invocations of the DOS command processor. In
- the simplest form, an extra command processor is obtained by
- typing COMMAND at the DOS level. Many multitasking or switching
- utilities also utilize this feature of DOS, and these utilities
- can now be managed via MARK and RELEASE.
-
- ================================================================
-
- Due to the way DOS handles batch files, there are certain
- limitations on using RELEASE within batch. It is *not* possible
- to perform the following sequence of events successfully:
-
- First, from the command line:
-
- MARK
- SK {SideKick, or any other resident program or programs}
-
- Then, within a batch file:
-
- RELEASE {get rid of SK and MARK}
- LOTUS {run Lotus using the additional memory}
- MARK {put SK back in place}
- SK
-
- DOS allocates a small memory block prior to running any batch
- file. It does not allow that block to be deallocated from within
- the batch file without various errors occurring. As a result, in
- this case the MARK and SK memory blocks are effectively trapped
- until the batch file is completed, after which the memory will
- be reusable. Indeed, if you run the batch file presented above,
- you will get MARK and SK installed above a big hole in memory
- left by the previous images of MARK and SK.
-
- As of version 1.9, RELEASE guards against this possibility. If
- it senses that you are attempting to release memory trapped by a
- "batch control block", it writes a warning message to that
- effect. It still releases the memory, but when it exits it
- passes back a return code of 1 rather than the usual value of 0.
-
- It *is* possible to get the desired effect in either of at least
- two ways. First, you could make two batch files and call them
- one after the other:
-
- Batch file #1:
- RELEASE
-
- Batch file #2:
- LOTUS
- MARK
- SK
-
- In this case, running RELEASE in batch file #1 has the same
- effect as running RELEASE from the command line. However,
- directly calling the second batch file from the first doesn't
- always seem to work either. The only sure bet appears to be the
- use of a keypoker like STACKEY, KEY-FAKE or PCED's KEYIN,
- modifying Batch #1 as follows:
-
- RELEASE
- KEY-FAKE "batch2" 13
-
- A better way to make these things happen is to use the public
- domain program CED, or its commercial upgrade PCED. These
- programs allow you to define "synonyms" for groups of commands.
- The commands execute one after the other just like a batch file.
- However, the synonyms do not create an extra batch control
- memory block which causes the problems just described.
-
- Thus you could make two CED synonyms as follows. (We assume that
- the CED "chain character" is ^).
-
- SYN LOADSK mark !sk^sk
- {create a protected sidekick marker and load sidekick}
-
- SYN RUNLOT release !sk^lotus^mark !sk^sk
- {release sidekick if it's there, run lotus, then reload sidekick}
-
- ================================================================
-
- As of version 2.0, a new form of marking, called a "file
- mark", is also supported. The new mark has the advantage that it
- uses only about 150 bytes of memory rather than the 1600 of MARK.
-
- The new mark is placed with the command
-
- FMARK [d:][directory]filename
-
- The bulk of the vector table and EMS page map are stored in the
- file which you specify on the command line rather than in
- memory. Note that a command line parameter is *required* in this
- case. Otherwise FMARK will halt with an error. The file created
- by FMARK will be between 1000 and 2000 bytes in size, depending
- on usage of expanded memory.
-
- If you will switch drives or directories after using FMARK, you
- should specify a complete pathname when FMARK is initially
- called. To avoid confusion, you may want to keep the FMARK files
- in the root directory, or in a separate directory defined just
- for this purpose.
-
- The RELEASE program has been upgraded so that it can release
- either an in-memory mark (placed by MARK.COM) or a file mark
- (placed by FMARK.COM). Use of RELEASE with in-memory marks is
- the same as before. To use RELEASE with file marks, call it with
- the name of the mark file on the command line:
-
- RELEASE [d:][directory]filename
-
- Note that in this case the filename must be specified on the
- command line, and that only a file mark exactly matching the
- command line will be released. If the specified mark file is not
- found, RELEASE will halt with an error message. When the memory
- is released, the mark file is also deleted from disk.
-
- There is no direct equivalent of protected marks for FMARK. If
- an unnamed RELEASE finds an in-memory mark below a file mark,
- the file mark will be released in the process of the unnamed
- release. In this case, the mark file will not be deleted from
- disk.
-
- ================================================================
-
- Version 2.1 of RELEASE fixes a stupid bug in 2.0. This bug lead
- to reports of RELEASE printing its status message on the
- printer, and to some system crashes. The bug was caused by
- writing over the first two bytes of the DOS file handle table at
- offset 0018H in the PSP.
-
- ================================================================
-
- Version 2.2 of RELEASE adds a few new features. These features
- are activated by command line switches. The valid switches are
- as follows:
-
- /K release memory above the specified MARK, but Keep the
- MARK itself in memory. This switch is useful if you plan
- to reinstall the released TSRs later.
-
- /R Revector the 8259 interrupt controller(s) to powerup
- state. This option is useful for TSRs that patch in to
- the system at a very low level. Examples include network
- operating system shells, multitaskers, etc. Use this
- option with caution; that is, test it at some point when
- no useful work has been loaded into memory.
-
- /? Show a brief help screen and halt.
-
- Any of these options are acceptable when preceded by a '-', for
- example, -K instead of /K.
-
- The /R option now allows the release of DesqView, Windows, and
- TaskView from memory. We hope that it will allow the release of
- network shells, but have not been able to test it. DoubleDOS
- unfortunately cannot be released even with the /R option. (It
- apparently patches DOS itself when it is installed.)
-
- Version 2.2 of RELEASE also restores a few additional memory
- locations from the MARK. It restores 8 bytes at 40:A8
- (associated with the EGA) and 16 bytes at 40:F0 (the
- interapplications communications area).
-
-
- B. MAPMEM and WATCH
- ================================================================
-
- MAPMEM.COM is used to display the current DOS memory map. It shows
- the resident programs, how much memory they use, and what interrupt
- vectors each currently controls. MAPMEM also shows information
- about expanded memory when such a driver is installed. MAPMEM
- writes to the standard output -- thus the output can be printed
- or stored to a file by using DOS redirection.
-
- MAPMEM shows MARKs and FMARKs so that you can look at them prior
- to a RELEASE. A MARK will show the owner name "MARK", and the
- mark name (if any) in the command line area. An FMARK will show
- "N/A" in the owner column (due to the minimal memory kept by an
- FMARK), and the name of the mark file in the command line area.
-
- WATCH.COM is a resident program that watches other memory
- resident programs become resident. As a TSR goes resident,
- WATCH updates a small file that contains information about what
- interrupt vectors were taken over. This information can later be
- used by MAPMEM to show more details about interrupts than
- normally available. Installation of WATCH.COM is optional. All
- of the other TSR Utilities can be used whether or not WATCH is
- installed.
-
- If you want to use it, WATCH.COM should be installed as the
- first TSR in your AUTOEXEC.BAT file. WATCH creates two files:
- \TSR.INI and \TSR.DAT (in the root directory of the default
- drive at boot time). TSR.INI contains a list of the interrupt
- vectors at the time WATCH was installed. TSR.INI is not
- currently used after it is created - it is a hook for future
- capabilities that may become part of the TSR Utilities. TSR.DAT
- is updated after each memory resident program is installed in
- your system. For each resident program, it contains a line
- similar to the following:
-
- 0E40 14|0E40:005C 17|0E40:009C
-
- All numbers are reported in hexadecimal. The first number is the
- segment at which the program became resident. Each group of
- characters following the segment shows an interrupt vector that
- was changed by the resident program. The first byte is the
- interrupt number and following the '|' is the segment:offset of
- the new value of the interrupt vector. Thus, by scanning TSR.INI
- and TSR.DAT, the status of the interrupt vector table can be
- recreated at any point in the TSR installation sequence.
-
- At this time, TSR.DAT is used only to aid MAPMEM in one of its
- report modes.
-
- As of version 2.2, MAPMEM supports the following command line
- options:
-
- /W [Watchfile]
- Used in combination with WATCH.COM, this option
- causes MAPMEM to show the vectors taken over when
- each program went resident, not just those still
- controlled when MAPMEM is run. If Watchfile is not
- specified, the file \TSR.DAT is used.
- /V Verbose report.
- /? Write a brief help screen.
-
- MAPMEM accepts either "/" or "-" to delimit the command line
- options.
-
- On the Verbose report, the "Files" column shows the number of
- file handles that each resident block has kept open. Each block
- of memory reported by DOS is listed individually in verbose
- mode. This is useful in debugging problems, either with the TSR
- package itself, or perhaps with the resident programs that you
- are using.
-
- By default, each "hooked vector" that MAPMEM reports shows only
- the current owner of the vector. Any previous owners now chained
- onto the list are not shown. Because of the technique used,
- MAPMEM may report some garbage hooked vectors (generally high
- numbered ones). When the /W option of MAPMEM is used, however,
- MAPMEM reads the TSR.DAT file and shows the vectors for which
- any TSR gains control as part of the chain. No garbage vectors
- should appear when the /W option is used. The optional filename
- for the /W option allows you to specify the TSR.DAT file on
- another drive.
-
- The MAPMEM /W option may not work correctly if TSRs are released
- and reinstalled. Extra interrupt vectors will be reported in
- some cases. Solving this problem would greatly complicate
- WATCH.COM.
-
- WATCH.COM may not work correctly on floppy-based systems where
- the disk in drive A: is changed during operation. WATCH creates
- \TSR.DAT when it is installed. When other programs go resident,
- WATCH assumes that \TSR.DAT already exists. If the file is not
- found, WATCH will not create it or update it, and MAPMEM /W
- reports will be incomplete.
-
- Everything we know about DOS memory allocation is embodied in
- the source code for MAPMEM and RELEASE. We found this out by
- piecing together tips from friends and through many hours of
- snooping. Please don't call for an explanation.
-
-
- C. RAMFREE and EATMEM
- ================================================================
-
- RAMFREE.COM supplies a quick way to determine the amount of free
- RAM (without going through CHKDSK). RAMFREE also reports the
- segment at which the free memory block begins.
-
- EATMEM.COM is useful for program development work when you want
- to test software in an environment with a desired amount of
- available memory. Note that the memory used by EATMEM can be
- freed by using MARK and RELEASE. EATMEM is called with a single
- command line parameter, specifying the (decimal) number of
- KILOBYTES to eat up:
-
- EATMEM KiloBytesToEat
-
- Note that EATMEM will happily allow you to eat up all system
- memory, leading to a crash when COMMAND.COM cannot be reloaded.
- Be sure to calculate how much memory to eat before calling
- EATMEM.
-
-
- D. The Story Behind the TSR Utilities
- ================================================================
-
- These programs should work on any system running PCDOS or
- MSDOS 2.0 or later. They were developed on a Compaq Deskpro 286
- running Compaq DOS 3.0 and have subsequently been tested on a
- number of different systems. Complete source code is available
- in the file TSRSRC.ARC. MARK, FMARK, WATCH, RAMFREE and EATMEM
- are written in assembly language (CHASM), while MAPMEM and
- RELEASE are written in Turbo Pascal. TSRSRC requires that you
- have Turbo Pascal version 3. On CompuServe, TSRSRC is found in
- the Borland SIG (Go BOR-100) in data library 4 (DL4).
-
- The programs have been released to the public domain for personal,
- non-commercial use only. You may use them yourself, give them to
- your friends or co-workers, or distribute them for a cost-based
- fee as part of a user's group or bulletin board service. If you
- wish to distribute these programs as part of a commercial package,
- please contact us for a license agreement.
-
- These programs were originally developed as an exercise in
- understanding DOS memory management. They have been put in the
- public domain as a public service. We ask for no donation for
- this set of programs. If for some reason you want the latest
- version or need support, we will ask for $5 to cover the costs
- of shipping a new disk to you.
-
- TurboPower Software is in the business of Turbo Pascal
- programming tools for serious developers. Our first product, the
- TurboPower Utilities, contains 9 programs including an
- intelligent cross-reference, a pretty printer, an execution
- profiler and several DOS file and text management tools. Our
- second product, Turbo EXTENDER, lets Turbo Pascal programs grow
- beyond 64K bytes in size via modular compilation and linking. It
- also provides a toolbox of routines for virtual array
- management, as well as analytical tools for overlayed
- programs. Our third product, T-DebugPLUS, is an expanded and
- fully supported version of the popular public domain program
- TDEBUG. It includes both a fully symbolic debugger integrated
- with the Turbo Pascal development environment, and also the
- ability to generate DOS standard MAP files for use with other
- external symbolic debuggers such as Periscope, Symdeb, and Atron.
-
- The TSR Utilities were written by Kim Kokkonen, with thanks to
- Neil Rubenking for the original idea behind MARK and RELEASE.
- Also my thanks to Richard Wilson and Barry Simon at CalTech for
- the idea that lead to FMARK, and much useful correspondence
- about the TSR Utilities.
-
- We can be reached at:
-
- TurboPower Software
- 3109 Scotts Valley Drive #122
- Scotts Valley, CA 95066
- 408-438-8608
- Compuserve: 72457,2131
-
- Version 2.2 - 3/4/87